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(71) We, International Business 
Machines Corporation, a Corporation or- 
ganized and existing under the laws of the 
State of New York in the United States of 
5 America, of Armonk, New York 10504, 
United States of America, do hereby declare 
the invention, for which we pray that a 
patent may be granted to us, and the method 
by which it is to be performed, to be par- 
10 ticularly described in and by the following 
statement; — 

This invention relates to controlled access 
systems. 

For reasons of public convenience and 

15 economy a variety of systems have been de- 
veloped for executing user requested transac- 
tions. One example is a check cashing ma- 
chine. Such a machine reads data from a 
check inserted therein and issues cash equal 

20 to the amount of the check if the check is 
found to be in order. Other systems have 
been developed for use in conjunction with 
credit cards. 
One credit card system stoics credit card 

25 account information in a central data base. 
In response to the submission of an account 
number from a remote terminal, the sys- 
tem provides information relating to the ac- 
count. For instance, the system may indi- 

30 cate that the card has expired, this it has been 
stolen or may indicate the dollar amount of 
available credit After a transaction is com- 
pleted the system properly adjusts the stored 
information to account for the transaction. 

35 Other credit card systems are frequently 
used by banks to extend their services dur- 
ing times of heavy business or business clos- 
ure, permit the issuance of cash or the re- 
ceipt of deposits through a terminal. Such a 

40 terminal typically includes a mechanism for 
receiving and reading information from a 
credit card, a keyboard, a display and docu- 
ment entry and exit apertures. The termi- 
nal may operate in conjunction with a data 

45 base or as a stand alone unit. Increased secur- 
ity for the issuance of cash without human 



intervention it attained by issuing a personal 
ID number with each credit card. A credit 
card transaction is then enabled only when, 
an ID number corresponding to the account 50 
number read from the credit card is entered 
through the keyboard. This required cor- 
respondence prevents a thief or mere finder 
of a credit card from receiving cash from a 
terminal If a terminal operates in con- 55 
junction with a data base the correspondence 
between account numbers and ID numbers 
can be chosen at -random, but frequently the 
ID number is derivable from the account 
number in accordance with a predetermined 60 
code. This predetermined relationship per- 
mits a stand alone terminal to check the ID 
number by algorithmically relating the ID 
number to the account number. 

While this dual credit card and ID num- 65 
ber identification technique improves the se- 
curity of cash issue terminals, there are still 
weaknesses that may be exploited to gain 
access to the large amounts of cash that are 
stored in the terminals. For instance it may 70 
be necessary to employ a substantial number 
of computer operators, programmers, analysts 
and other people at the host data base who 
have at least limited access to information 
stored in the host data base. It would be 75 
possible for any of these people to compile 
lists of account numbers and corresponding 
ID numbers to be used in conjunction with 
forged or stolen credit cards to obtain cash. 

An equally serious problem relates to the 80 
security of the encryption algorithm for ter- 
minals which are capable of stand alone 
operation. A large number of operators or 
maintenance personnel are required for the 
day-to-day support of cash issue terminals. 85 
For example, one or two people at each 
branch bank location may have internal 
access to the cash issue terminals. Often 
times these people may have access to the 
encryption key for normal maintenance 90 
Alternatively, with only a little training these 
people could learn to acquire the key by 
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measuring electrical signals on the internal 
circuitry. Once the encryption key is ac- 
quired, a correspondence between a large 
number of account numbers and ID numbers 
5 could be generated. 

Another possible security problem arises 
from the transmission of account information 
and ID information between a terminal and a 
host data base. These transmissions often 

10 involve utility communication lines and are 
therefore subject to monitoring by a large 
number of people. Encryption is often used . 
to improve communication security but any- • 
one who is able to break the code or gain 

15 access to the code would be able to extract 
and compile a list of correspondence be- 
tween credit card account information and 
ID numbers by monitoring these transmis- 
sions. In addition, by generating fake ter- 

20 rninal communication traffic a person might 
gain access to the host data base and fraudu- 
lently transfer funds within data base ac- 
counts. Thus, while protected against a com- 
mon thief, conventional systems which use 

25 this dual identification technique are not 
adequately protected against a sophisticated 
thief having knowledge of modern data pro- 
cessing equipment. 
The present invention provides a con- 

30 trolled access system including testing means, 
a request station incorporating encoding 
means, a control station incorporating encod- 
ing means and a communication system for 
transmission of data between the request 

35 station, the control station and the testing 
means, the arrangement being such that a 
request for access includes the entry of two 
messages at the request station, one of which 
is encoded at the request station, the other 

40 being encoded at the control station, the test- 
ing means being arranged to generate an ac- 
cess enabling signal if there is correspondence 
between the encoded forms of the two mes- 
sages. 

4 ~> Clearly once right of access is determined, 
subsequent activity depends on the nature 
of that to which access is granted. 

The invention will be described further by 
way of example with reference to an embodi- 

50 ment of the invention as illustrated in the 
accompanying drawings in which : 

Figure 1 is a functional block diagram 
representation of a transaction execution sys- 
tem in accordance with the invention; 

55 Figure 2 is a functional block diagram re- 
presentation of a transaction terminal used in 
the transaction execution system shown in 
Figure 1; 

Figure 3 is an operational block diai*ram 
60 representation of the. manner in which a 
user initiated transaction request is initially 
processed by a transaction terminal; 

Figure 4 is an operational block diagram 
representation of the manner in which tran- 
65 saction requests received by a transaction 



terminal are processed by a host data pro- 
cessing system; and 

Fig. 5 is an operational block diagram re- 
presentation of the manner in which a tran- 
saction reply message from a host is pro- 70 
cessed by a transaction tenninal. 

Introduction 

A transaction execution system 10 in ac- 
cordance with an embodiment of the inven- 75 
don includes a host data processing system 
12 and a plurality of user transaction ter- 
minals 14 in communication therewith. The 
host data processing system 12 includes a 
host central processing unit 16 such as an 80 
IBM system 370 (IBM being a Registered 
Trade Mark), a communication controller 
18 such as an IBM 3705 and a data base 
20 which may include electrically alterable 
random access memory, magnetic tape trans- 85 
ports, and magnetic disks. The host CPU 
performs the arithmetic and logical opera- 
tions which are required for controlling the 
operation of the host data processing sys- 
tem 12 and processing information which is 90 
received through the communication con- 
troller 18 or stored in the data base 20. The 
data base 20 stores information which is 
related to each customer of the host cen- 
tral processing system 12. For instance, for 95 
a banking customer, the data base might 
store account information for credit card, 
savings, checking or other accounts of the 
bank as well as payroll information and 
information relating to the financial status of 100 
the bank's operations. Each account might 
be typically addressable in accordance with 
an account number and have stored therein 
the current account information such as the 
current balance, a history of account trans- 105 
actions for a predetermined period of time, 
encoded personal ID numbers for persons 
who^ are authorized to use the account, a 
maximum credit limit, and any other infor- 
mation the bank may wish to store as part of 1 10 
an account. The communication controller 
18 acts as an interface between the CPU 16 
and a plurality of communication channels 
22. The controller 18 arranges information 
received by the host 16 into a communication 115 
discipline and maintains communication syn. 
chronization. 

A transaction terminal 14 may be con- 
nected for communication with the host data 
processing system 12 in an almost unlimited 120 
number of ways with the various methods 
shown in Fig. 1 being only exemplary. For 
instance, a terminal may be connected 
directly to the communication controller 18 
by either a local communication link such 125 
as cable 24 for local user transaction termi- 
nal 26 or a utility or radio link 28 for a re- 
mote user transaction terminal 30. Alterna- 
tively, a terminal may be connected to the 
host central processing system 12 through a 130 
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controller 32 such as an IBM 3601 by 
either direct connection to the controller 32 
as by cable 34 for terminal 36 or by connec- 
tion in a communication loop 38. Although 
5 other devices may be included, the communi- 
cation loop 38 is illustrated by way of an 
example as including a first teller work sta- 
tion 40, a second teller work station 42, 
a first user transaction terminal 44 and a 

10 second user transaction terminal 46. While 
the communication loop 38 may include re- 
mote transmission links such as radio com- 
munication or communication over commer- 
cial utility lines, for a bank system, the 

15 controDcr 32 might typically be located at a 
branch bank with all the data processing 
terminals at the branch bank being connected 
into the loop 38. The controller 32 is con- 
nected to a communication channel 22 of 

20 communication controller 18 through a com- 
munication link 48 such as a utility communi- 
cation line as shown in Fig. 1 though it could 
be connected in a communication loop which 
extends to a communication channel 22 of 

25 communication controUer 18. A description 
of one such communication system may be 
found in United States Patent Specification 
No. 3,921,137. 
In general, the controller 32 merely acts as 

30 a relay device for information which is passed 
around the loop 38 but may also serve as the 
host data processing system when immediate, 
real time communications with the host data 
processing system 12 are not maintained. 

35 When serving as the host, the controller 32 
must store transaction execution informa- 
tion for later processing by the system 12 
and must provide host support functions 
which are required for operation of a ter- 

40 mind 14. 

Transaction Execution Terminal 
A preferred embodiment of the transaction 
terminal 14 is shown in Fig. 2. The terminal 

45 14 is generally modular in nature and in- 
cludes a programmable microprocessor 60 
coupled to a plurality of terminal subsystems 
by an information bus 62. The microproces- 
sor 60 is driven by a clock signal from clock 

50 signal generator 64 and is operationally con- 
nected to a data storage module 66 provid- 
ing both electrically alterable random access 
memory (RAM) and read only storage 
(ROS). The read only storage portion of the 

55 data storage 66 stores the various operating 
programs for the microprocessor 60. The 
random access memory portion of data stor- 
age module 66 provides a scratchpad for pro- 
gram execution. With typical IC memories 

60 the contents of the RAM are lost in the event 
of a power failure. 

Terminal Information Bus 
The microprocessor 60 communicates with 
65 the modular subsystems^solely through the 



terminal information bus 62. This tech- 
nique of interconnecting modular subsystems 
with the microprocessor 60 through the bus 
62 permits the microprocessor 60 to re- 
ceive detailed information on the tenninal 70 
status and maintain detailed direction of 
terrninal hardware operations without a 
large number of input and output informa- 
tion connections. The task of sensing ter- 
minal status information is performed by 75 
the individual terrninal subsystems. This 
information is then transferred to the micro- 
processor 60 on command from the micro- 
processor 60. Similarly, the driver cir- 
cuitry and hardware for executing micropro- 80 
cessor commands is contained wMiin the 
subsystem modules. The microprocessor 
commands are extremely basic and detailed 
in nature. Each command accomplishes a 
basic subsystem operation such as the activa- 85 
tion or deactivation of a motor, the display 
or printing of a character, the feeding of a 
bill or the reading of a communication char- 
acter. The information bus 62 includes a 
system reset signal, 9 data input signals (8 90 
bits + parity) for carrying information to 
the processor 60, 9 data output signals (8 
bits + parity) for for carrying information 
from the microprocessor 60 to an operable 
connected subsystem, and bus control signals 95 
for controlling the transfer of information 
onto and off from the bus 62. 

Processor Support Subsystem 
One of the operational subsystems which 100 
is connected through bus 62 to micro- 
processor 60 is processor support subsystem 
68. Processor support subsystem 68 provides 
hardware assistance to the microprocessor 60 
in contrast to other terrninal subsystems 105 
which have functions related to particular 
aspects of terminal 14 operation. 

Processor support subsystem 68 receives 
a 1 MH 5 clock signal from clock signal gen- 
erator 64 and divides this signal to generate HO 
lower frequency clock signals which are used 
in the other subsystems. One lower frequency 
clock signal is utilized for the generation of 
period interrupt commands at 10 msec, inter- 
vals. These interrupt commands cause in- 115 
terrupt logic within processor support sub- 
system 68 to generate a microprocessor inter- 
rupt every 10 msec. The microprocessor 60 
utilizes these clock period interrupts to main- 
tain an event control time base for the 120 
various operations of the terminal 14. Reset 
logic within subsystem 68 controls the reset 
line of the information bus 62. Activation of 
this reset line causes initialization of the 
processor 60 as well as all modules which 125 
are connected to bus 62 and cancels any 
pending user transaction. The processor 60 
is returned to a predetermined program in- 
struction from which program execution can 
begin anew following the reset. The reset 130 
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signal is activated in response to AC power 
on, a reset switch, or a hang signal from a 
hang detector within operational hardware 
subsystem 68. The hang detector monitors 
5 the control lines of the bus 62 and generates 
a hang signal when bus activity ceases for 
a length of time which is sufficient to indi- 
cate that the microprocessor 60 is not operat- 
ing properly. A run detector responds to 

10 the timer interrupt request signals and gen- 
erates a run signal which is maintained ac- 
tive so long as the microprocessor regularly 
responds to the requests. If a predeter- 
mined period of time elapses without the 

15 processing of a timer interrupt request, the 
run detector terminates the run signal. The 
processor support subsystem 68 also in- 
cludes read data logic which receives a 
string of serial information as it is read from 

20 a user credit card, separates the data from 
the clocking information, deserializes the 
binary bit stream and places the informa- 
tion on the bus 62 for processing by the 

^ microprocessor 60. 

Mechanical Control Subsystem 
A mechanical control subsystem 70 pro- 
vides the actual mechanical manipulation of 
various hardware features of the terminal 

30 14. Subsystem 70, which like the other 
subsystems has no branching or decision 
making capability, executes basic, elemental 
commands from the microprocessor 60 and 
collects information on the physical status 

35 of the various hardware functions for com- 
munication back to microprocessor 60. As 
an example of the individual elementary 
nature of functions which are executed by 
mechanical control subsystem 70, a credit 

40 card handler mechanism responds to a credit 
card direction and move commands to acti- 
vate a motor which drives a card conveyor 
system to move the credit card beneath a 
read head. Sensors (switches or photocells) 

45 are positioned to sense the presence of the 
credit card at (1) entry, (2) exit iam sensor, 
and (3) card escrow positions. When a sen- 
sor is activated an information bit is avail- 
able in a status word to indicate this condi- 

50 tion. When the microprocessor 60 periodic- 
ally reads the various status words during a 
read operation is determines that the credit 
card has reached the escrow area where 
the card is held. Processor 60 then com- 

55 mands that the credit card feed motor be re- 
versed for a short period of time to "brake", 
and then commands that the motor be turned 
off. In similar elemental fashion, the mecha- 
nical control subsystem 70 controls the com- 

60 plete processing of the credit card such as 
retention or return to the user. Other func- 
tions include control of the depository 
wherein the user may deposit documents 
which are passed into a retention bin in 

65 such a manner that the user never has access 



to the retention bin. Similarly, the mecha- 
nical subsystem 70 controls the opening and 
closing of user access doors and the issu- 
ance of predetermined amounts of cash to 
an escrow area at which printed transaction 70 
statements may also be accumulated along 
with the cash and the issuance or retention of 
documents presented to the escrow area. In 
addition to sensing the status of mechanical 
hardware which is manipulated by mecha- 75 
nical control system 70, the control sub- 
system 70 senses the presence of cash stored 
by the cash issue hardware and indicates 
when there is not enough cash available to 
execute a maximum issue transaction. Sub- 80 
system 70 also senses several conditions that 
may be communicated to a remote control 
panel as well as the processor 60. These 
remote signals include an indication of 
whether the service door is opened, whether 85 
or not a penetration sensing grid has been 
disturbed, and whether or not an "interven- 
tion required" condition exists. Other sig- 
nals which may be communicated to the re- 
mote panel include transaction statement 90 
forms or cash low, operator access service 
door open, communication between the ter- 
minal and host ready. Command switches 
located on a remote panel may include a 
terminal reset switch and a wrap switch 95 
which commands a test of the communica- 
tion link. 

User Communication Subsystem 
A user communication subsystem 72 con- 100 
trols bidirectional communications between 
the terminal 14 and a user. The communica- 
tion subsystem 72 includes a keyboard for 
receiving user generated commands, a dis- 
play of 222 horizontal dots by 7 dots and 105 
includes display control logic and a refresh 
buffer. The display control logic receives 
the "dot image" of the particular display 
and then continues the display until a con- 
trary command is received. no 

The keyboard is divided into several fields 
with a plurality of keys in each field. For in- 
stance, a transaction selection field indicates 
the type of transaction a user wishes to exe- 
cute. Other fields include a from account 115 
select field indicating an account from which 
funds are to be taken, a to account select 
field indicating an account to which funds 
are to be deposited and a numeric keyboard 
field permitting the entry of decimal num- 120 
bers such as personal ID numbers or dollar 
amounts. "Back lights" are provided on 
the function select, to account, and from ac- 
count keys to generate an audit trail indicat- 
ing to a user which keys have been selected 125 
in previously used fields. All back lights 
are Muminated in the field in which the 
next key activation should occur. For in- 
stance, as a user inserts his credit card into 
the terminal 14 he is requested to key in 130 
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his personal ID number. After proper re- 
ceipt of the ID number all of the keys in 
the function selection field would become 
lighted. As the user activates a particular 
5 key, such as a funds transfer key, the other 
back lights are extinguished with only the 
funds transfer key remaining backlighted. 
All keys in the next field such as the from 
account field are then illuminated in prepar- 

10 ation for the next step in the transaction re- 
quest In this way an audit trail is provided 
to indicate previous selections and the next 
selection field is also indicated. Display 
messages and color coding may also be used 

15 to guide the user in the proper sequence. 
The keyboard control logic of the user com- 
munication subsystem 72 includes the cir- 
cuitry necessary to back light specific keys 
commanded by the microprocessor 60 and to 

20 indicate the microprocessor which keys have 
been activated by a user. 

Transaction Statement Dispenser 
A transaction statement dispenser subsys- 

25 tern 74 includes a form handler for trans- 
porting transaction statement forms, a 
printer, printer control logic and logic 
for interfacing the subsystem 74 with 
subsystem 74 performs only specific, basic 

30 commands such as starting movement or 
printing of specific characters. The subsys- 
tem 74 collects information on the physical 
status of the transaction statement dispenser 
hardware for communication through bus 62 

35 to the microprocessor 60. This information 
is then used by the microprocessor 60 which 
operates under program control to detect the 
successful completion of a particular ele- 
mental function and commands the intiation 

40 of additional functions. 

Operator Function Subsystem 
An operator function subsystem 76 pro- 
vides operator maintenance interfacing and 

45 includes entry switches, a four digit hexa- 
decimal display, power sense circuitry, a 128 
byte power off protected auxiliary memory 
which is used for storing system parameters 
and logging exception information. Stored 

50 parameters include a cash counter number, 
encryption keys and a transaction number. 
Access to the operator panel is through a 
double locking door at the rear of the ter- 
minal 14 which must be closed for user oper- 

55 ation.^ Opening of the access door and at- 
tempting a maintenance function causes 
destruction of encryption keys which are 
normally stored in this auxiliary memory. 
This destruction of the keys provides 

60 security of the keys from an operator who 
migjht seek to use electronic instruments to 
read the key from the non-volatile memory. 
The kevs must then be re-entered through 
the keyboard by a person of high trust be- 

65 fore the terminal can be reopened. The 8 



byte keys are each entered at 16 hexadecimal 
digits two digits at a time. Only the two 
preceding digits are displayed as the keys 
are entered to increase the difficulty of an 
interloper discovering the keys. Altema- 70 
tively, a Key A which defines the corres- 
pondence between account numbers and 
personal ID numbers may be even further 
protected by requiring entry of a de* 
encrypted Key A (Key A 1 ) which is en- 75 
crypted in accordance with an encryption 
key to produce the actual Key A. Using this 
technique the actual Key A can remain 
secure from all personnel at the phsyical 
location of the terminal 14. The power 80 
sence circuitry monitors both the AC utihty 
voltage level and the internal DC power 
levels and in the event of an indication that 
AC power is lost and the DC voltage levels 
are low but still usable, a signal is sent to 85 
the microprocessor 60 causing critical in- 
formation to be saved and then access to the 
auxiliary memory is restricted while the 
memory is driven from an auxiliary power 
source. An indication signal is provided to 90 
the operator panel so long as the DC logic 
voltages are adequate. 

Communication Subsystem 
A communication subsystem 78 provides 95 
communication interfacing between a com- 
munication channel and the information bus 
62. Communication subsystem 78 is conven- 
tional in nature and receives information 
from or provides information to terminal in- 100 
formation bus 62 one byte at a time. 

Remote Connector 
A remote signal connector 82 permits the 
connection of some status signals and some 105 
control signal inputs to a remote control 
panel which is actually part of the terminal 
14. For instance, a bank branch might have 
five terminals 14 and a single centralized re- 
mote control panel with optical displays and 1 10 
control switches for each of the five term- 
inals 14 at a convenient centralized location. 
These remote signals are primarily for moni- 
toring terminal operation or control and are 
not utilized for normal user transaction. 115 

Communication Message Format 
There are essentially two different types 
of messages which may be sent from a term- 
inal 14 to a host data processing system and 120 
four types of messages which may be sent 
from the data processing system 12 to a 
transaction terminal 14. The terminal to host 
message include a transaction request mes- 
sage which is the normal first communica- 125 
tion message following a user initiated 
transastion and a status message which is 
typically the last of a three message 
sequence. There are two basic types of status 
messages. The first is a reply status message 130 
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which serves as the third communication 
message in a normal user transaction 
sequence and informs the host of the com- 
pletion or cancellation of a user requested 
transaction. The second is an exception 
status message which indicates a status or 
condition for a terminal 14 other than a 
normal operating condition. For example, 
an exception status message would be sent 
in reply to an inquiry command from the 
host data processing system, when the ser- 
vice door is opened, upon detection of a 
serious error condition such as a user door 
jam or a hard machine failure or any time 
initialization is required. 

The four types of messages which may be 
transmitted from a host data processing 
system 12 to a transaction teiminal 14 in- 
clude a transaction reply message, command 
message, a load initialization message, and 
an echo message. The transaction reply 
message is the normal response to a transac- 
tion request message during the course of a 
normal user transaction and informs the 
terminal 14 of the manner in which the re- 
quested transaction should be completed. A 
command message commands changes in a 
teiminal 14 logical state and may also serve 
as an inquiry for a status message if no 
changes are desired. A load initialization 
message is sent from a host to a terminal 14 
in response to an exception status message 
requesting initialization QPL). The load 
initialization message contains message text, 
option selection information, font tables, 
program routines, and data information for 
storage in the volatile random access por- 
tion of data storage 66 of the micropro- 
cessor 60 within a terminal 14. An echo 
message is used as a diagnostic assurance 
test and can be sent only when a terminal 14 
is in a closed state. The terminal 14 re- 
sponds to an echo message with an echo 
message. 

There are only three basic message se- 
quences which may be used for the com- 
munication of messages between a terminal 
14 and a host data processing system 12. A 
single message sequence consists of an ex- 
ception status message transmitted from a 
terminal 14 to a data processing system 12. 
The exception status message may either in- 
dicate that an abormal condition has 
occurred or be a request for initialization. 
A "command message" from the host is 
not required. The message contents indicate 
which is the case. 

A two message sequence may include 
either a command message (a load initializa- 
tion message) from host processing system 
12 to a tenninal 14 followed by an appro- 
priate status message from the tenninal 14 
to the host data processing system 12 or a 
host echo message followed by a terminal 
echo message. The transaction terminal 14 



will reject a command that is received while 
the terminal is processing a previous com- 
mand, an unintelligible message, or an un- 
requested transaction reply message. In 
each instance the host may be either a re- 70 
mote system or a directly connected local 
system. 

Each time the tenninal 14 assumes an 
initial power on condition, for whatever 
reason, the terminal 14 must request and 75 
receive a load initialization message from 
the host data processing system before the 
tenninal 14 can be reopened to accept 
transactions. Transactions terminals such as 
terminals 36, 44, and 46 in Fig. 1, which 80 
are connected to a controller 32 may oper- 
ate in an off-line mode. Under such circum- 
stances, the controller 32 serves as the host 
data processing system and merely records 
user transactions, for example on magnetic 85 
tape or disc. The transaction information 
is then made available to a transaction 
accounting system at a later time to permit 
the updating of accounts. If operating on- 
line mode, some host functions may be 90 
handled by the controller 32 such as storage 
of the initialization program for the term- 
inals, but normally all communications are 
merely communicated to the host data pro- 
cessing system 12 without change. In such an 95 
on-lme mode of operation, the host data 
processing system 12 may update account 
records stored in its data base in real time; 
that is as user requested transactions are 
executed. joo 

Each time a terminal 14 loses power in- 
formation is lost from the RAM portion of 
data storage 66, and initialization must be 
requested at power turn-on. After the re- 
ceipt of initialization information from the 105 
host a terminal 14 may be opened to receive 
user transactions, but only on command 
from the host. Initialization is accomplished 
by a terminal 14 using the single message 
format to send an exception status message 110 
requesting initialization. The host data pro- 
cessing system then initiates a new com- 
munication sequence by sending an initial- 
ization message (in multiple parts) contain- 
ing the requested initialization information 115 
Upon successfully receiving the initialization 
information the requesting tenninal 14 com- 
pletes the two part message sequence by 
sending a status message back to the host 
data processing system. 120 

Every message which is sent between a 
transaction terminal 14 and a host data pro- 
cessing system 12 begins with a four byte 
header field. Byte 1 of the header field is a 
message length byte (L) containing a binary 125 
count of the number of message bvtes in the 
message text (including L). Byte 2 is a I byte 
transaction sequence number (N) in binary 
form. This number is incremented for each 
new user transaction and is included in all 130 



7 



1,458,495 



7 



messages exchanged for that transaction. 
The number has a range of 1 to 255 inclu- 
sive. Zero (hex 00) is used for messages that 
do not relate to a user transaction. Thus, a 

5 transaction number counter which is incre- 
mented for each new user transaction over- 
flows from hex FF to hex 01. The transac- 
tion number (N) is stored in the power out 
protected auxiliary memory of operator 

10 function sub-system 76 so that it remains 
available after a short term power outage. 
Byte 3 of the common header field is a class 
byte (Q which identifies the type of mes- 
sage and thus the format of the message 

15 which is being sent. Byte 4 is the final byte 
of the header field and identifies a message 
sub-class (SC) which serves as a modifier 
to the message class byte. 
Only a few of the possible combinations 

20 of message classes (Q and sub-classes (SC) 
are actually implemented. Class hex 01 
identifies a transaction request message from 
a terminal 14 to a host data processing 
system. Within class 01, nine sub-classes 

25 have been implemented. Sub-class hex 00 
indicates that a user requested transaction 
is incomplete because the ID number has not 
been properly entered. Sub-class hex 01 
indicates a cash issue request. Sub-class hex 

30 02 indicates an account inquiry. Sub-class 
hex 03 indicates that a user is requesting to 
deposit funds. Sub-class hex 04 indicates 
that a user is requesting to transfer funds 
from one account to another. Sub-class hex 

35 05 indicates that a user is requesting to pay a 
loan or bill by depositing money in the 
transaction terminal. Sub-class hex 06 in- 
dicates a transaction wherein the nature of 
the transaction is identified by entry of a 

40 predetermined number through the keyboard 
rather than by activation of a single key 
in the transaction selection field of the key- 
board. Sub-class hex 07 indicates that a re- 
quested transaction is incomplete because 

45 the deposit flap covering the deposit bin has 
been jimmied. Sub -class hex 08 indicates 
a user request to pay a bill or loan by the 
transfer of funds from one account to an- 
other. 

50 A class of message designated C=hex 15 
identifies a status message from a terminal 
14 a host data processing system 12. There 
are five sub-classes of messages under this 
class. Sub-class hex 01 indicates a transaction 

55 completion status message. Sub-class hex 
02 indicates that the message is in response 
to the execution of a command and the 
status number, N, in the common header 
must be set to 0. Sub-class hex 03 is an 

60 exception status message indicating an error 
condition or requesting initialization and the 
transaction number N must be set to 0. Sub- 
class hex 04 indicates that the status mes- 
sage is in response to initialization and the 

65 transaction number N must be set to 0. Sub- 



class hex 08 is a recovery request or com- 
mand response message and the transaction 
number N must be set to 0 for this message. 
A recovery request indicates that the host 
has lost track of the current transaction and 70 
requires an update. The terminal responds 
with an exception status message. 

A transaction reply message from a host 
data processing system to a transaction 
terminal 14 is indicated by class hex 0B. 75 
There are nine sub-classes indicated by the 
sub-class byte under this sub-class. Sub-class 
hex 00 indicates that the transaction is in- 
complete because the ID number was not 
properly entered. Sub-class hex 01 indicates 80 
a cash issue transaction request. Sub-class 
hex 02 indicates an account inquiry transac- 
tion request Sub-cless hex 03 indicates a 
deposit transaction request. Sub-class hex 

04 indicates a funds transfer transaction re- 85 
quest in which funds are to be transferred 
from one account to another. Sub -class hex 

05 indicates a transaction request for the 
payment of a loan or bill by transfer of funds 
deposited in the terminal to an account. 90 
Sub-class hex 06 indicates an optional selec- 
tion transaction wherein the nature of the 
transaction is determined in accordance with 

a number entered through the numerical key- 
board rather man by the activation of a 95 
single key in the transaction selection field 
of the user keyboard. Sub-class hex 07 in- 
dicates that the message relates to a re- 
quested user transaction which is incomplete 
because the deposit flap of the terminal 14 100 
has been jimmied. Sub-class hex 08 in- 
dicates a user transaction wherein a loan 
or bill is to be paid by transferring funds 
from one account to another. 

Qass hex 0C identifies a command mes- 105 
sage from the host data processing system 
to a terminal 14. A command message does 
not relate to a particular transaction and 
therefore the transaction number N of the 
header field is always set to 0. Sub-class hex 110 
01 indicates an open command. Sub-class 
hex 02 indicates a command to close the 
transaction terminal 14. Sub -class hex 03 in- 
dicates an inquiry type of message in which 
a transaction terminal 14 may not perform 115 
any function in response to the command 
but must respond with a status message. 
Sub-class hex 04 indicates a command to 
change the third key (key B) which is the 
transmission encryption key from the 120 
present key to a key contained within the 
message. Sub -class 05 indicates a command 
to set the transmission encryption key (key 
B) using a back up key (key C). Sub-class 
hex 06 indicates that a transaction terminal 125 
14 is commanded to request an initial pro- 
gram load. Sub-class hex 07 indicates that 
the message includes a command to either 
change the optical display or contains a 
written message to be printed by the transac- 130 
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tion statement dispenser. Sub-class hex 08 
is a command for transaction terminal 14 to 
send a class hex 15 sub-class hex 08 re- 
covery request message back to the host. 
5 The load initial program message from the 
host to a transaction terminal is designated 
class hex 0D and has only one sub-class 
which is designated hex 01. 
An echo message from the host data pro- 

10 cessing system to a terminal 14 is desig- 
nated by class hex 10. Within this class 
there are four sub-classes of echo messages. 
Sub-class hex 00 is the basic echo message 
and merely commands the transaction term- 

15 inal 14 to retransmit the echo message back 
to the host data processing system. Sub- 
class hex 01 indicates an echo canned mes- 
sage command which is both checked for 
bit pattern and echoed. The bytes of data 

20 in the canned text are designed to send all 
possible bit patterns to check the operation 
of communication facilities. The message 
pattern is retained by the terminal for com- 
parison with a second transmission of the 

25 message pattern. An echo variable record 
sub-class designated hex 02 is similar to the 
canned echo sub-class except that the mes- 
sage may contain host entered data. The 
transaction terminal echos the message back 

30 and also retains the message in storage for 
comparison with a second transmission of 
the same message. Upon receipt of the 
second transmission of the message, the 
transaction terminal checks and echoes as 

35 for sub-class 01. A log data request mes- 
sage is designated sub-class 03. This wtil 
cause the terminal to send the 8 most cur- 
rent error log records. No encryption or de- 
cryption is involved in the transmission of 

40 any echo message. 

The four byte common header field of 
each message is followed by the message 
data in a format that depends upon the par- 
ticular type of message that is being sent. 

45 For a transaction request message from the 
terminal 14 to the host data processing 
system bytes 1 — 4 of the common header 
are followed by bytes 5 — 8 which contain a 
32 bit encrypted field. This 32 bit encrypted 

50 field will be discussed in greater detail later, 
but in general the field includes an encrypted 
form of the personal ID number which was 
entered through the user keyboard and one 
byte of varying information which may be 

55 either the contents of a cash counter or a 
transaction number counter. 

Byte 9 is a from account select (FAS) 
byte indicating which key within from 
account selection field of the user keyboard 

60 was activated. The data content of this 
ninth byte indicates the type of account from 
which the funds for the user requested 
transaction are to be taken. Hex 21 in- 
dicates from a checking account, hex 22 

65 indicates from a savings account, hex 23 



indicates from a credit card account, and 
hex 24 indicates from an optional selection 
account, which is further defined by a 
numeric modifier. By making special ar- 
rangements with the bank, a user can open 70 
multiple accounts. These accounts can then 
be assigned predetennined three digit (deci- 
mal) numbers. By activating the optional 
selection from account key on the keyboard 
the user is then permitted to enter up to 75 
three decimal numbers through the 
numerical keyboard to indicate which of 
possibly many predefined "accounts he wants 
debited. This account identification number 
is transmitted one digit per byte and bytes 80 
10-A where A may assume the values 10, 
11 or 12 depending on whether the key- 
board determined account number contains 
1, 2 or 3 digits respectively. Because the 
FAS field may have a variable length, it must 85 
be followed by a field separator (FS) byte 
having the data content hex FE. which is 
used to define the limits of variable length 
fields. Adjacent field separators indicate a 
zero length of no entry field between them. 90 
The FS byte delimits the end of the field 
preceding the FS byte. 

Following the FS byte for the from 
account select (FAS) field is a to account 
select (TAS) field designating an activated 95 
key within the to account select field of the 
user keyboard. Hex 31 indicates that funds 
are to be deposited to a checking account, 
hex 32 indicates to a savings account, hex 
33 indicates to a credit card account, and 100 
hex 34 indicates to an optional selection to 
account select key which may be modified 
by up to three digits (decimal) iromediately 
following the first TAS byte. These numeric 
modifiers have the same meaning in the TAS 105 
field as in the FAS field Because the TAS 
field is variable in length it must also be 
followed by a field separator (FS) byte hav- 
ing data content hex FE. Following the field 
separator byte for the to account select field, 1 10 
the data which is read from the magnetic 
stripe on the credit card is transmitted. By 
removing the parity bit from the standard- 
ized code of the American Bankers Associa- 
tion, it is possible to pack the two four bit 115 
characters of credit card data in each byte 
of the message. In the event that an odd 
number of credit card characters appears on 
the credit card, the last byte is padded with 
a hex F to fill all bytes of the message. Start 120 
of card characters, end of card characters 
and longitudinal redundancy check (LRQ 
characters are excluded from the transmitted 
transaction request message in as much as 
they are checked by the terminal 14. 125 

A status message from a terminal 14 to 
the host data processing system begins with 
the four byte common header field identify- 
ing the message length (L), transaction 
number (N), message class (Q, and message 130 
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sub-class (SQ for the message, in byte posi- 
tions 1 — 4, Byte positions 5 — 8 contain a 
32 bit encrypted field. This 32 bit field will 
be discussed in greater detail below but in 
5 general contains a repetition of the eight bit 
transaction number (N), eight bits repre- 
senting the revolving cash count for de- 
nomination two (CNTR2), eight bits in- 
dicating the number of status bytes (CB) 

10 and eight bits representing the re- 
volving cash count for denomination one 
(CNTR1). The byte CB is a one byte 
field containing a -binary count of a number 
of status and inquiry data bytes which fol- 

15 low the encrypted portion (bytes 5 — 8) of 
the message for a normal status message. 
For a "request recovery message" the CB 
field contains the "action field" from the 
transaction reply for the last transaction 

20 request message. The "action" field is an 
eight bit field transmitted as part of the 32 
bit encrypted field of a transaction reply 
message. The eight bit counter portions 
(CNTO.) of the 32 bit encrypted field in- 

25 dicates binary count of bills issued by the 
second and first cash issue mechanism. These 
numbers are taken from counters which are 
incremented for each issued bill and roll 
over from hex FF to hex 00. The counts 

30 are stored in the auxiliary memory of the 
operator function subsystem 76 so that the 
count is preserved during a short term power 
outage. Following the 32 bit encrypted field 
at bytes 5 to 8 is a data field. The data field 

35 includes a four byte status field in byte posi- 
tions 9 — 12. These four bytes define the cur- 
rent status of a terminal 14 as discussed be- 
low. Most status messages terminate with 
an FS byte at byte position 13. However, a 

40 status message which is sent in response to 
an inquiry command message contains 112 
of the 128 bytes stored in the auxiliary 
memory of the operator function subsystem 
76 which are transmitted behind tine four 

45 status bytes. For this message the field CB 
would contain the number 116. The 16 bytes 
of the non-volatile memory which are not 
sent in response to an inquiry message con- 
tain the two eight byte encryption keys. If 

50 the status message is being resent in re- 
sponse to a request recovery message, the 
four status bytes contain the four bytes of 
the last transaction status message and are 
followed by the complete original transac- 

55 tion request message. This information then 
would allow the host to re-construct the 
conditions which existed prior to the event 
which caused the host to request recovery. 
The 32 bit positions of the four status 

60 bytes at byte positions 9—12 of a status 
message each have a predetermined mean- 
ing. These meanings are assiened to define 
the physical and operating status of a term- 
inal 14 with sufficient oarticularity that a 

65 host data processing system can assess and 



control the geenral operation of each term- 
inal 14. These meanings are described in 
tabular form below with the number to the 
left indicating the status byte number rang- 
ing from 0 to 3 with status byte 0 in status 70 
message byte position 9 and status byte 3 in 
status message byte position 12. For each 
status byte there are 8 bits designated bit 
0— bit 7 with bit 0 being in the most sig- 
nificant bit position and bit 7 in the least 75 
significant bit position. 



Byte Bit Description 

80 

0 0 Transaction completion status bit. 
This bit position is set to logic 1 
at the beginning of each transac- 
tion to indicate that the transac- 85 
tion has not been completed be- 
cause a transaction reply mes- 
sage is required. The bit position 
is reset to logic 0 when a tran- 
saction has been executed as 90 
specified in a transaction reply 
message. 

0 1 Invalid transaction sequence num- 
ber in transaction reply bit. This 95 
bit position is reset to logic 0 each 
time a new transaction is started. 
The bit position is set to logic 1 
any time the transaction number 
(N) within the common header 10O 
field of a message received from 
the host data processing system 
is inaccurate. An exception is 
made for an echo message which 
does not convey meaningful in- 105 
formation in the transaction 
number position of the header 
field. 

0 2 Invalid transaction subclass in 110 
reply message bit This bit posi- 
tion is reset to logic 0 each time a 
new transaction is started and is 
set to logic 1 any time a transac- 
tion reply message is received 115 
containing a different number in 
the fourth or subclass byte of the 
common header field from that 
of the transaction request mes- 
sage. Byte 0 bit 0 must be set 120 
simultaneously with this bit posi- 
tion. 

0 3 Invalid class bit. This bit position 

is reset to 0 after an exception 125 
status message has been sent and 
is set to logic 1 any time a mes- 
sage is received from the host 
data processing system containing 
an invalid class designation in 130 
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Byte Bit Description 



Byte Bit Description 



10 0 4 



15 



20 



25 



30 



byte 3 of the common header 
field. As an example, a terminal 
14 might receive a nonrequested 
initialization (IPL) message or a 
nonrequested transaction reply 
message. 

Amount error in transaction re- 
ply message bit This bit position 
is reset to logic 0 at the beginning 
of each new transaction and set to 
logic 1 any time a transaction 
reply message is received with the 
dollar amount byte within the 
encrypted field thereof indicating 
an improper dollar amount. Bit 0 
of byte 0 must be set to logic 1 
any time this bit position is set 
to logic 1. 



0 5 Unassigned. 



Customer cancelled transaction 
bit This bit position is reset to 
logic 0 at the beginning of each 
new transaction and set to logic 1 
in the event that a customer acti- 
vates a cancelled key on the user 
keyboard subsequent to the trans- 
mission of the transaction of a 
transaction request message. 



35 0 7 User timeout bit This bit posi- 
tion is reset to logic 0 at the be- 
ginning of each new user transac- 
tion and set to logic 1 any time a 
user consumes more than an al- 

40 lotted predetermined length of 

time in entering a number 
through the user keyboard or in 
depositing materials through the 
deposit flap. Bit 0 of byte 0 must 

45 be set any time this position or 

position 0 6 is set to logic 1 . 

1 0 Command reject bit This bit posi- 
tion is reset to logic 0 after a com- 

50 mand status message is sent The 

bit position is set to logic 1 upon 
receipt of a command message 
which cannot be executed because 
the terminal 14 is busy at the 

55 time a command is received. 

1 1 Invalid command bit This bit 
position is reset to logic 1 upon 
sending a command status mes- 

60 sage. The bit position is set to 

logic 1 any time a command 
message is received with missing 
fields therein. For instance, a key 
change command which does not 

65 include the new key or a change 



display command without a new 
display field. This bit position is 
also set to logic 1 in response to 
a command message containing 
an invalid subclass designation in 
byte 4 of the common header 
field. 



70 



75 



1 2 IPL request bit This bit position 
is reset to logic 0 upon the 
proper receipt of a load initializa- 
tion message from the host data 
processing system and set to logic 80 
1 each time a terminal 14 goes 
from a closed to an open condi- 
tion, for example, upon closure 
of the operator/ customer engineer 
access panel, or upon command 85 
from the host data processing 
system. This bit is also set to 
logic 1 each time a terminal 14 
receives a command message 
commanding the terminal to re- 90 
quest an IPL. 

1 3 IPL and process bit. This bit 
position serves as a modifier bit 
for bit position 2 of byte 1. A 95 
combination of bit 2, bit 3 equal 
00 indicates that the terminal is 
initialized. This condition can 
occur only when the terminal is 
in an open state. Trie combina- 100 
tion of bit 2, 3 equal 10 indicates 
that initialization has been re- 
quested but the load initializa- 
tion message has not been re- 
ceived. A combination of bit 2, 3 105 
equal 11 indicates that a load 
initialization is in process. 

1 4 Cash counter error bit. This bit 

position is reset to logic 0 at the 110 
beg|nning of each new user tran- 
saction. The bit position is set to 
logic 1 any time a transaction 
reply message is received contain- 
ing a cash counter byte (CNTR) 115 
within the encrypted field thereof 
which does not match the status 
of the cash counter within the 
terminal. The cash counter is a 
rollover counter which is incre- 120 
mented each time a new bill is 
issued. Byte 0, bit 0 must be set 
to logic 1 each time this bit posi- 
tion is set to logic 1. 

125 

1 5 C and CS field error bit This bit 
position is reset to logic 0 upon 
sending an exception status mes- 
sage. It is set to logic 1 upon 
receipt of a command message 130 
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Byte Bit Description 



from the host data processing 
system containing a class and 
subclass (C&SQ byte within the 
encrypted data field that does not 
match the class and subclass byte 
of the common header field. This 
failure to match indicates a pos- 
sible encryption key synchroniza- 
tion error or host error. In a 
normal command message, the 
two class (Q and subclass (SQ 
bytes of the common header field 
are combined into a single class 
and subclass (C&SQ byte 
(packed by sensoring the four 
leading 0 bits of each byte). 

1 6 Communications timeout on tran- 
saction, reply sequence bit. This 
bit position is reset to logic 0 at 
the beginning of each new user 
transaction. The bit position is set 
to logic 1 any time a predeter- 
mined period of time expires fol- 
lowing the transmission of a user 
transaction request message with- 
out the receipt of a corresponding 
transaction reply message. Byte 
0, bit 0 must be set to logic 1 
any time this bit position is set 
to logic 1. 

1 7 Unintelligible message bit This 

bit position is reset to logic 0 
after sending an exception status 
message. It is set to logic 1 to 
indicate an unintelligible message 
any time a message is received 
which does not correspond to the 
required predetermined message 
format For example, the num- 
ber of bytes may not agree with 
the message length (L) designa- 
tion in the common header or a 
parity error may occur upon 
reading a data byte or a byte 
position may contain invalid 
data. 

2 0 Card retained bit This bit is reset 

to logic 0 at the beginning of 
each new user transaction and is 
set to logic 1 any time a user 
requested transaction is term- 
inated with the terminal 14 retan- 
ing the credit card which was 
inserted therein by the user. This 
bit position indicates that the 
card was retained as a result of 
a hardware error at the terminal 
14 rather than in response to a 
command from the host data 
processing system. 



Byte Bit Description 



2 1 Dispense error bit. This bit posi- 
tion is reset to logic 0 at the be- 
ginning of each new user transac- 70 
tion. The bit position is set to 
logic 1 any time an error occurs 
during the dispensing of a docu- 
ment such as a biD or a transac- 
tion statement This bit position 75 
is set any time a document is 
dumped from an escrow area into 
a retention bin. Since the transac- 
tion may be completed upon 
retry, this bit position does not 80 
necessarily indicate an incomplete 
user transaction. 

2 2 Unrecoverable depository error bit. 

This bit position is reset to logic 85 
0 at the beginning of each new 
user transaction. This bit posi- 
tion is set to logic 1 any time an 
error condition such as a jam 
occurs in the tenninal depository 90 
and the terminal is unable to re- 
cover from the error condition. 

2 3 Display table overflow bit. This 

bit position is reset to logic 0 95 
upon sending a status message. 
The bit position is set to logic 1 
upon receipt of a change display 
command message from the host 
data processing system containing 100 
more display data than the term- 
inal display system can handle. 
An improper display message is 
not accepted by a tenninal 14 

105 

2 4 Unassigned. 
2 5 Unassigned. 

2 6 Intervention required bit This HO 
bit is set when an intervention 
required condition occurs. It is 
reset when the intervention re- 
quired indicator is turned off. 

115 

2 7 Card removal timeout bit This 
bit position is reset to logic 0 at 
the begirining of each new user 
transaction. The bit position is 
set to logic 1 whenever a pre- 120 
d^ennined period of time expires 
following the availability of credit 
card to a user without the card 
being removed from a terminal 
14. This bit position indicates 125 
that some kind of intervention is 
required. Normally, the host data 
processing system would respond 
by commanding the tenninal to 
retain the credit card. 130 
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Byte Bit Description 

3 0 Open/close bit. This bit position 
is reset to logic 0 any time the 
5 terminal opens and is ready to 

receive a user transaction request. 
This bit position is set to logic 1 
each time the terminal closes. 

10 3 1 Cash out condition bit. This bit 
position is reset at the beginning 
of each new user transaction. This 
bit position is responsive to a 
hardware switch which indicates 

15 whether or not there is enough 

cash stored in the terminal to 
execute a maximum cash issue 
transaction. The bit position is set 
to logic 1 any time the cash out 

20 condition occurs during the 

execution of a preceding cash 
issue transaction to which the 
status message corresponds. The 
setting of this bit position in- 

25 dicates that intervention is re- 

quired and causes a terminal to 
close. 



Byte Bit Description 



30 



35- 



40 



45 



50 



55 



60 



65 



3 4 



3 5 



Invalid backup encryption key 
bit. This bit position is reset to 
logic 0 upon sending a status 
message and is set to logic 1 upon 
receipt of a change key type of 
command message from the host 
data processing system containing 
an improper encryption key (an 
improper encryption key contains 
all zeros). 

Transaction statement dispenser 
form out bit This bit position is 
reset to logic 0 at the beginning 
of each new user transaction. It is 
set to logic 1 when a transaction 
statement sensor indicates that 
the last usable transaction state- 
ment form is issued during the 
last preceding transaction to 
which the status message corres- 
ponds. 

Deposit flap (door) or issue gate 
open bit This bit position is re- 
set upon sending a status message. 
The bit position is set to logic 1 
when the deposit flap or issue gate 
remains open when it should be 
closed and indicates that the flap 
or gate has been jimmied. 

Unrecoverable hardware failure 
bit This bit position is reset to 
logic 0 after an exceotion status 
message has been set This position 
is set to logic 1 any time a jam or 



other error condition is en- 
countered which cannot be cor- 
rected, whether during the execu- 
tion of a transaction or at any 
other time. Setting of this bit 
position indicates that interven- 
tion is required and ttte terminal 
closes. 



70 



75 



3 6 Customer door open bit. This bit 
position is reset to logic 1 upon 
sending a status message. The bit 
position is set to logic 1 when the 80 
customer door which provides 
access to the user keyboard and 
display is open when it should 
be closed and indicates that the 
door has been jimmied. Setting of 85 
this bit indicates that interven- 
tion is required and causes the 
terminal to close. 

3 7 Security enclosure interlock bit. 90 
This bit position is reset to logic 
0 when the operator access door 
is closed and set to logic 1 when 
the door is open. The terminal 14 
closes any time this bit position is 95 
set to logic 1. 

A transaction reply message from a host 
data processing system 12 to a user terminal 
14 is generated in response to a user transac- 100 
tion request message. The transaction reply 
message begins with the standard four byte 
common header field specifying total mes- 
sage length {L), transaction number (N), 
message class (C), and message subclass 105 
(SQ. Following the four bytes of the com- 
mon header field are four bytes or 32 bits of 
encrypted information, a variable length 
optional display data field, a field separa- 
ter character (FS) and a variable length 110 
optional transaction statement print field, 
and a final field separation character (FS)! 
The four byte encrypted field includes a 
one byte cash counter 2 number (CNUl 2), 
a single action byte, a one byte cash counter 115 
1 number (CNTR 1), and an amount byte 
(AMT) which specifies the number of bills 
for which the reply message is authorizing 
issuance. The terminal 14 checks this 
authorized amount against the request. 120 

The action byte is a one byte instruction 
from the host data processing system 12 
which directs a terminal 14 to consummate 
a user transaction in a manner consistent 
with the data contents thereof. 125 

Bit 0. When bit 0 is set to logic 1, a 
terminal 14 is commanded to immediately 
display a standard terminal display message 
which is indicated by the optional display - 
data field immediately following the en- 130 
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crypted field. Up to 128 separate messages 
designated 0 — 127 are stored in data storage 
66 associated with the microprocessor 60. 
When bit 0 of the action byte is set to logic 

5 1 the terminal 14 is commanded to display 
one of these messages which is indicated by 
the binary content of the one byte optional 
display field at byte position 9 of the trans- 
action reply message. 

10 Bit 1. When bit 1 is at logic one term- 
inal 14 is commanded to immediately display 
an optional display message contained with- 
in the optional display data field immediately 
following the encrypted field When bit 1 is 

15 set to logic one, byte 9 at the beginning of 
the optional display data field contains a 
binary number indicating the length of the 
display message in bytes exclusive of byte 
9. Immediately following byte 9 the transac- 

20 tion reply message contains the text of the 
desired display message in EBCDIC code 
with each byte indicating one display 
character. 

Bit 2. A logic one at bit position two of 
25 the action byte indicates that a transaction 
terminal 14 is commanded to print informa- 
tion on a transaction statement and that the 
transaction statement print data field of the 
reply message contains the data to be 
30 printed in EBCDIC code. 
Bit 3 not defined. 

Bit 4. A logic one in bit 4 indicates that 
a requested user transaction is authorized as 
requested. 

35 Bit 5. A logic one in this bit position in- 
dicates that a user's credit card is to be 
retained by the terminal 14 while a logic 0 
indicates mat the credit card is to be re- 
turned to the user. 

40 Bit 6. A logic one in this bit position in- 
dicates that the user is required to ack- 
nowledge the transaction before the terminal 
14 proceeds to execute the transaction. The 
user acknowledges the transaction by activat- 

45 ing either a cancel key or a proceed key in 
a keyboard control field. Typically some in- 
dication of the transaction would be dis- 
played at the time the user selects a kev. 
For instance the message "TRANSFER 

50 S50.00 FROM SAVINGS ACCOUNT TO 
CHECKING ACCOUNT— depress cancel 
or proceed" might be displayed. 
Bit 7. Not defined. 

The transaction statement print field at 
55 the end of a transaction reply message is 
divided into a plurality of subfields which 
permit the communication of print data for 
ud to 2 transaction statement forms. The first 
subfield is a common data subfield which 
60 carries information such as the user's name 
and account number which will be the same 
for both transaction statements. The com- 
mon data field may either command a 
terminal 14 to print a canned print message 
65 stored within the memory 66 of a terminal 



14 or may command the terminal to print a 
message transmitted as part of the common 
data field and standard EBCDIC code. The 
first byte of the common data field deter- 
mines the source of the print data. If this 70 
byte contains a number from 1 to 127 (be- 
low hex 80) the print data is contained in 
standard EBCDIC form in the common data 
subfield immediately subsequent to the first 
byte. Li this instance, the first byte repre- 75 
sents a binary length count indicating the 
number of bytes of text in the common data 
field exclusive of the length byte. If the 
common print data is to be provided by a 
canned message, a print message ID number 80 
identifying the particular canned message is 
added to 128 (hex 80) and transmitted as the 
first and only byte of the common data sub- 
field. By way of example, if the common 
data is to be taken from a canned message 85 
number 30, the one byte common data sub- 
field would contain the binary number 
30+128=158 (hex 9E). A one byte data 
content corresponding to ID number 0 (hex 
80) is used as a deliminator for the com- 90 
mon data and statement data and must not 
be used to define message ^ as a canned 
message. A statement number one data sub- 
field immediately follows a dehminator byte 
hex 80 after the common data subfield. The 95 
statement number one data subfield may 
carry an actual EBCDIC print message or 
may identify a canned print message and 
uses the same format as the common data 
subfield. Print information commanded by 100 
the statement number one data subfield, how- 
ever, will be printed only on one transaction 
statement form designated form one. The 
deliminator character (hex 80) immediately 
follows the statment number one data sub- 105 
field. A statement number two data subfield 
immediately follows the second deliminator 
character. The statement number two data 
subfield has a format and data content simi- 
lar to the common data subfield and state- 110 
ment number one data subfield. The state- 
ment number two data subfield may contain 
either a transmitted print message in 
EBCDIC code or identify a canned print 
message. If the statement number two data 115 
subfield is not present, i.e, has a length of 
0 byte, a second transaction statement form 
is neither printed nor issued. A field separa- 
tor character (FS) immediately follows the 
statement number two data subfield to in- 120 
dicate the end of the transaction statement 
print field and the end of a transaction re- 
ply message. Printing of a transaction state- 
ment form begins in the upper left hand 
corner and proceeds left to right and line 125 
by line in the common English reading 
format. An EBCDIC carriage control code 
is utilized to terminate a fine of text and 
begin the printing of the next textual charac- 
ter at the left most character position of the 130 
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next line down. The printing operation 
follows a predetermined sequence in which 
common text is first printed on statement 
form one, statement one text is printed on 
5 statement form one, common text is printed 
on statement form two, and finally statement 
two text is printed on statement form two. 

A command message is sent from the host 
data processing system- 12 to a terminal 14 

10 to control the operation or status of the 
terminal in accordance with the data con- 
tent of the command message. Each com- 
mand message begins with a four byte com- 
mon header field and containing message 

15 length (L), transaction number (N), mes- 
sage class (Q and message subclass (SQ. A 
four byte encrypted field follows the four 
byte header field. The four byte encrypted 
field includes the cash counter byte 
-20 (CNTR1), the class and subclass byte 
(CNSQ containing both the class and sub- 
class indication combined into a single byte, 
a second cash counter byte (CNTR2), and a 
special byte (SPEC). The special byte is 

25 utilized for ah inquiry type of command 
message to indicate the information which is 
to be supplied by a responsive status mes- 
sage from a commanded terminal to the host 
data processing system. Bits 0-4 of the 

30 special byte are unassigned and are norm- 
ally transmitted as logic 0. Bit 5 is set to 
logic one to indicate that a terminal is being 
commanded to retransmit its last status mes- 
sage. Bit 6 is set to logic one to indicate 

35 that the terminal is to transmit a current 
status message plus the 112 bytes of 
auxiliary storage within operator function 
subsystem 76 which do not contain the two 
encryption keys. A logic one in bit 7 of the 

40 special byte indicates that the terminal is 
commanded to transmit a normal status 
message. Bits 5, 6 and 7 are mutually ex- 
clusive where only one should be on at a 
time. 

45 Two optional encrypted fields follow the 
common header field and four byte en- 
crypted field of a command message. The 
first optional encrypted field carries a first 
half of an eight byte encryption key and 
50 the second optional encrypted field carries 
the second half of an eight byte encryption 
key. These first and second optional en- 
crypted fields are included only following a 
set key or change key command. A terminal 
55 14 responds to a change key command by 
deencrypting the command message with 
the old third or transmission encryption key 
{key B) and then substituting the key re- 
ceiyed in the optional encrypted fields one 
• oo and two for all future communications. A 
set key command operates like a change 
key command except that the new key is 
encrypted in a backup key (key Q stored 
m the auxiliary memory. In a "change dis- 
cs play message" type of command message the 



two optional encrypted fields are not included 
in the message but a clear text optional data 
field follows the four byte encrypted field. 
The clear text optional data fidd begins with 
an index number (INDX) followed by a data 70 
field length byte (LD) and new display text 
in standard EBCDIC code. A "change 
display message" type of command message 
does not affect the actual display which is 
visible by a terminal user, but instead modi- 75 
fies the data content of a canned display 
message stored within the data storage 66. 
For example it may be desirable to change 
a canned display message "take out credit 
card" having a display message ID number 80 
40 to 'remove credit card". The index byte 
(INDX) contains the display message ID 
number of the canned message which is to 
be changed The data field length byte (LD) 
contains a binary number indicating the 85 
number of bytes in the text of the new mes- 
sage which immediately follows. If the new 
message is too long to fit into the number 
of bytes available in the table of display 
messages within data storage 66, the com- 90 
mand is not executed and the following 
status message indicates that the command 
was not executed. Because the display mes- 
sages are of a variable length and because 
it is necessary for all messages from the 95 
host data processing system to a terminal 
14 to contain an even number of bytes it 
may be necessary to pad the end of a dis- 
play text with an arbitrary pad character. 
This pad character would not be counted 100 
for the data field length byte (LD) but would 
be counted for the overall message length 
byte (L) in the common header field of the 
command message. 

The load initialization message provides 105 
the information for the random access 
memory portion of data storage 66 which 
may have been lost in the event of a power 
shut down. It may also be used to reinitialize 
the terminal with new options. This mes- 110 
sage begins with the standard four byte 
common header field, follower by a two byte 
binary number field specifying the number 
of bytes in the following data field. The data 
field comprises the last field of the load 115 
mitialization message and contains the 
customization image which is stored in data 
storage 66. The critical information such as 
micro program routines and option selection 
bytes in the data field is encrypted with the 120 
third trarismission key (key B) in four byte 
sequential segments. 

t In general, the customization image which 
is received during initialization provides the 
information which may vary from one term- 125 
inal to another and is therefore not readiJy 
implemented with read only memories. In- 
cluded within the customization image are 
the canned user display and print messages 
which may include up to 49 predetermined 130 
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messages designated message 1 — 49. Also 
included as message 50 is an optional font 
table containing up to 574 bytes which per- 
mits the display of non-standard characters 

5 or graphics which have been custom selected 
by a given terminal customer such as a 
bank. Also included in the customization 
image is a certain amount of programming 
and program control information to account 

10 for the particular combination of available 
options which is implemented with a given 
terminal. 

Transaction Message Assembly 

15 The communications which are involved 
between a host data processing system 12 
and a user transaction terminal 14 during 
the execution of a requested user transaction 
are illustrated in further detail in the opera- 

20 tional block diagrams of Figs. 3 — 5 to which 
reference is now made. In order to facilitate 
an understanding of the operation of the 
invention, the operative communication 
system will be described in the context of 

25 specific user transaction examples. It should 
be appreciated however, that a transaction 
terminal 14 may perform any one of a large 
variety of user requested transactions and is 
not limited to these specific examples. 

30 For a specific example it will be assumed 
that the terminal 14 is a through the wall 
teiminal providing a walk up station at a 
branch bank. The through the wall terminal 
will be assumed to be connected in a manner 

35 similar to terminal 46 (Fig. 1) in a loop to 
a controller 32 and through the controller 
32 to a host data processing system 12. The 
terminal 46 extends through an exterior wall 
of the branch bank with the user communi- 

40 cation facilities outside the bank and the 
majority of the terminal inside the bank. 
The operator maintenance access panel is 
accessible via the service door from the in- 
terior of the branch bank. As a potential 

45 user approaches the terminal 46 the ulumina- 
tion of the keyboard area and a sign on the 
face of the terminal indicates that the term- 
inal is in an available (open) condition. No 
light and a "closed" display indicate that 

50 the terminal is unavailable for the execution 
of transaction if the terminal is in a closed 
condition and any user action is ignored. If 
the terminal indicates an open condition, the 
prospective user initiates a user transaction 

55 by inserting his credit card into a slot In 
this example, it will be assumed that a user 
desires to transfer funds from his savings 
account to his checking account. 

60 1. Transaction Request Message 

The first portion of the three part user 
transaction communication sequence is illus- 
trated in Fig. 3. The terminal microprocessor 
60 is shown only generally in Fig. 3 with no 

65 specific connections being made to physical 



or functional blocks. It will be apreciated 
that logical interconnection are as shown in 
Fig. 2 and that operational control and data 
processing are performed by the program 
microprocessor 60. 70 

At the time the prospective user is issued 
a credit card 100 by the customer bank, 
he is also assigned a six digit peronal identi- 
fication (ID) number. This personal ID 
number may optionally be related to in- 75 
formation recorded on a stripe of magnetic 
material on the credit card 100. As the card 
100 is inserted into the terminal 46 the pre- 
sence of the card is sensed and a credit card 
transport mechanism draws the card into the 80 
terminal 14 and past a read head where the 
card is sensed for proper orientation and 
status. If the card is improperly oriented 
contains unreadable data, or of a type which 
cannot be accepted by the terminal 46 it is 85 
returned. (If the card is expired it may be 
retained upon host command.) Assuming 
a proper credit card, the card 100 is trans- 
ported past a card reader 102 where the in- 
formation on the magnetic stripe is read and 90 
stored in the random access portion of data 
storage 66 and the card is detained at a card 
escrow holding area. The credit card 100 
is compatible with standards set forth by 
the American Bankers Association. This 95 
means that the magnetic stripe contains a 
sequence of five bit words representing a 
parity bit and four data bits. The four data 
bits include a start of card (SOC) character, 
a field separator character and an end of 100 
card (EOQ character. Numerals are in- 
dicated in binary coded decimal representa- 
tion. A typical magnetic stripe format be- 
gins with a start of card (SOQ character 
followed by an account number of up to 19 105 
characters, a field separator character, four 
characters specifying a month and year of 
the credit card expiration date, a discretion- 
ary data field, an end of card (EOC) charac- 
ter and a longitudinal redundancy check 110 
character. A maximum of 40-5 bit charac- 
ters may be recorded on the magnetic stripe. 
As the characters are read a selection key 
designated kl which is provided as an initial- 
ization option detennines a starting point for 115 
selecting 8 sequential characters from the 
magnetic stripe. For example, if kl contains 
the number 5, the fifth through 13 charac- 
ters following SOC are selected at step 104 
without their parity bits to form 32 bits. 120 
These 32 bits are processed in an encryption 
algorithm 106 to generate 32 bits of en- 
crypted data. 

The comparison of part or all of a per- 
sonal ID number with corresponding credit 125 
card information may be selectively provided 
as a customer option which is indicated at 
the time of initialization. It the comparison 
option is not selected the correspondence 
between ID numbers and credit card in- 130 
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formation may be randomly selected How- 
ever, the execution of a correspondence 
comparison is then impossible if the terminal 
14 operates under control of an off line 
5 host. If the local check option is selected, 
two keys indicate the manner in which the 
check is executed. 

The first check key, kl, permits the selec- 
tion of any contiguous group of 8 characters 

10 read from the credit card. Key kl identifies 
the position following SOC of the first of 
the 8 characters. The 8 characters would 
typically, but not necessarily, be chosen to 
be entirely within the credit card account 

15 number field. In the present example 
Kl=5 causing characters 5—13 to be 
selected. 

The second check key, K2, determines 
which digits within the personal ID number 

20 are to be checked by indicating the digit 
position at which the check is to begin. Thus, 
k2=l would cause digits 1 — 6 to be 
checked, k2=4 would cause digits 4—6 to 
be checked and k2=6 would cause only the 

25 least significant digit to be checked. As the 
number of checked digits increases (ie. k2 
smaller), the protection against fraud by 
guessing at ID numbers is increased for off 
line host operation. However, the locally 

30 checked digits must have a predetermined 
correspondence with credit card informa- 
tion while non-checked digits may have a 
random correspondence. Increasing the 
number of locally checked digits thus de- 

35 creases the number of digits available for 
random correspondence and increases the 
opportunity for access to the data base of 
an on line host in the event that the cor- 
respondence algorithm and encryption key 

40 becomes compromised. For the present ex- 
ample it is assumed that the customer has 
exercised his option by selecting the local 
check feature with k2=4. 
The particular encryption algorithm which 

45 determines the correspondence between ID 
numbers and credit card information is not 
critical to the practice of this invention ex- 
cept that the relationship between the clear 
text input and encrypted text output should 

50 be dependent upon an encryption key desig- 
nated here the first encryption key, Key A. 
For the purpose of this example it will be 
assumed that the encryption algorithm is 
of the type designated Lucifer in an article, 

55 H. Feistel, "Cryptography and Computer 
Privacy", Scientific American, May 1973, 
pp. 15—23 or in an article, C. H. Meyer, 
"Enciphering Data for Secure Transmis- 
sion", Computer Design, April 1974, pp. 

60 129 — 134. An encryption key such as Key 
A, for the algorithm 106, is a word contain- 
ing 64 binary diigts. The encryption key 
can also be thought of as including 8-8 bit 
bytes. Key 8 is stored within the auxiliary 

65 memory portion of operator function sub- 



system 76 and occupies 8 of the 128 memory 
words therein. In order to provide com- 
plete protection for this key, the key is des- 
troyed each time a maintenance function 
from the customer interface panel is re- 70 
quested. This destruction prevents an ordin- 
ary terminal maintenance person from gain- 
ing access to the code. In one arrangement 
a trusted bank employee having access to 
Key A waits until the maintenance person 75 
completes terminal maintenance and then 
enters the 64 bit code as 8 sequentially 
entered hexadecimal digit pairs. An opera- 
tor panel hexadecimal display indicates 
entered digits to permit correction if neces- 80 
sary with only the two most recently 
entered digits being displayed at any given 
time. This restriction of the display to two 
digits protects the security of the key by 
requiring a person trying to copy the key by 85 
observation of the display to observe the 
display for a considerable period of time by 
making it impossible to observe the entire 
key at one instant as the key entry is com- 
pleted. Once the key is entered it cannot be 90 
again displayed. It is thus possible to directly 
enter key A into the terminal as described 
above. 

However, in an alternate example the 
trusted bank employee is given not Key A, 95 
but a Key A 1 having a predetermined rela- 
tionship to Key A. In this example the 
trusted employee enters Key A 1 into the 
terminal in the same manner as if he were 
entering Key A itself. However, the term- 100 
inal processes Key A 1 with an encryption 
algorithm 108 which may be similar to or 
even identical to encryption algorithm 106 
to produce the encryption Key A. The 
encryption algorithm 108 uses a second en- 105 
cryption key designated Key C which is a 
terminal back up key in the encryption pro- 
cess which converts Key A 1 to Key A. Al- 
ternatively, a completely separate key could 
be loaded at initialization for this purpose. 110 

Because of the predetermined relationship 
between the 32 bits of credit card data which 
is encrypted with Key A and the 6 digit 
personal ID number which is given to a 
person at a time a card is issued, the 115 
security of Key A is extremely important. 
If a class of credit cards is to be usable at 
more than one branch of a customer bank, 
then at least one person at each bank must 
have access to Key A so that it can be 120 
keyed into a terminal 46 when necsessary. 
For a large bank with many branches this 
distribution can become quite wide. Further- 
more, if a card is to be usable interchang- 
ably at more than one bank, all banks 125 
accepting the card must have the same en- 
cryption Key A. The number of persons hav- 
ing access to Key A is thus further increased 
and can become quite substantial. The use of 
encryption algorithm 108 provides security 130 
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against this wide distribution of Key A. By 
using a different Key C at each banking 
unit only a predetennined Key A 1 corres- 
ponding to the given Key C will operate 

5 satisfactorily to produce the highly import- 
ant Key A. For example each unit might 
be a separate branch bank having three or 
four of the terminals 14. Only the Key A 1 
for that unit or branch bank will satisfac- 

10 torily produce the Key A. If a person hav- 
ing access to Key A 1 at one branch goes to 
a different branch, where a different Key C 
is employed in the encryption algorithm 108, 
the Key A 1 from the first branch will not 

15 produce the Key A at the second branch. 
It is thus possible to limit the distribution of 
Key A to a very small, highly select group 
of people. 

Encryption algorithm 106 thus produces 

20 as an output 32 binary digits having a pre- 
determined relationship to the 32 bit input. 
These 32 output bits are divided into 6n5 bit 
words in a table conversion process 110 
with only 30 bits being used. For instance, 

25 the words may be formed from the first 6 
groups of five sequential bits each with the 
last two bits not being used. Each group of 
five bits is utilized in table conversion pro- 
cess 110 as an address word in accessing a 

30 table storing one decimal digit of value 1 — 9 
at each address location. The table con- 
version thus results in 6 digits, each having 
a value of 1 — 9. These digits have a direct 
correspondence to the personal ID number 

35 and the digit 0 is excluded in order to avoid 
personal ID numbers which start with lead- 
ing 0's and can be expected to create con- 
fusion or variable length entries. 
If the information on the credit card is 

40 found to be in order, a user access panel is 
opened to provide user access to the optical 
user display and user keyboard 112. The 
user is directed to enter his personal ID 
number through the numeric field of the key- 

45 board. If the user does not enter exactly six 
digits within a predetermined period of time, 
an incorrect ID number is assumed and a 
retry is suggested. Upon entry of exactly 
six digits, a portion or the whole of the 

50 entered ID number is optionally compared 
with the 6 digit number generated by table 
conversion 110. The key K2 indicates which 
of the six corresponding pairs of digits are to 
be compared. 

55 In this example it has been assumed that 
K2=4 so that the three least significant 
digits having positions 4, 5 and 6 are com- 
pared by compare step 114. If the com- 
parison is invalid, a faulty ID number is in- 

60 dicated and the user is invited to retry entry 
of the ID number. If the ID number is not 
properly entered in a given number of re- 
tries such as 3, the transaction request is 
terminated and a message is sent to the host 

65 Upon host command the credit card is pre- 



ferably transported to a retention bin to 
prevent further use of the credit card in 
random attempts to match an ID number 
with a possibly stolen credit card. Alterna- 
tively, a credit card may be returned to the 70 
user. Upon determination that the compared 
digits of the keyed ID number match the 
corresponding digits which were obtained 
from the credit card, the six digits of the 
personal ID number are converted to a 32 75 
bit binary code at step 116. In step 116 the 
first 24 bits are obtained directly from the 
6 entered digits. The last 8 bits or 1 byte is 
obtained by treating each sequential pair of 
four bit digits as a single byte and taking the 80 
successive "exclusive or 1 ' of corresponding 
bit positions in each of the resulting three 
bytes to obtain the data content of the cor- 
responding bit position in the fourth byte. 
Other means of obtaining the last 8 bits of 85 
information are acceptable so long as the 
method results in variable information which 
is a function of all bits of the entered ID 
number. These 32 bits are then processed 
with an encryption algorithm 118 using Key 90 
A to produce a 32 bit encrypted personal ID 
number. The encryption algorithm 118 may 
in general be any suitable encryption al- 
gorithm, but for this example it will be pre- 
sumed that it is identical to the encryption 95 
algorithm 106. Use of the same algorithm 
for both encryption processes permit use of 
the same stored program or hardware logic 
for both processes. The encryption key for 
algorithm 118 may also be in general any 100 
suitable key. However, for this example it is 
assumed that algorithm 118 utilizes Key A 
which is identical to the Key A utilized for 
algorithm 106. This multiple use of the same 
encryption key as well as the same encryp- 105 
tion algorithm further reduces the complexity 
of the terminal 14 operation and the size 
of the required data storage.. The 32 bits 
which result from encryption algorithm 118 
thus represent an once encrypted personal 110 
ID number. 

The 32 bits of the encrypted personal ID 
number are then converted in step 120 to 6 
four bit digits with two four bit digits being 
droped. In step 122 the two discarded digits 115 
are replaced by two four bit digits of vari- 
able data. This replacement of ID number 
derived information with variable informa- 
tion prevents the encrypted field from being 
a constant. In general the variable data may 120 
be any data which has no predetennined 
relationship to the personal ID number and 
which varies with each transaction request 
message. In this preferred embodiment, the 
variable data is a cash counter (CNTR) 125 
count for cash issue transactions and a trans- 
action number (N) for other transac- 
tions. 

The 32 bits which result from the com- 
bination of the six four bit digits and the 8 130 
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bits of variable data are then passed 
through an encryption algorithm 124 which 
utilizes a third encryption Key B. Encryption 
algorithm 124 may in general be any suitable 
5 encryption algorithm. But for this preferred 
embodiment it will be assumed that algor- 
ithm 124 is identical to algorithm 118, 
algorithm 106, and algorithm 108. Key B is 
a 64 bit encryption key which is received 

JO from the host data processing system 12 
during initialization and which cannot be 
changed except by communication of a new 
key from the host data processing system. 
The encryption algorithm 124 results in 32 

15 bits of encrypted data which are assembled 
in a transaction request message immediately 
behind the four byte common header as des- 
cribed previously. 
After the compare step 114 at least par- 

20 tially validates the credit card, the user is 
instructed to indicate the transaction which 
he is requesting by use of the keyboard 112. 
The user is first instructed to indicate the 
type of transaction which is being requested 

25 and all of the back lights in the transaction 
request field of the keyboard are illumin- 
ated. As a particular key, which in this case 
would be the funds transfer key, is activated, 
the back light of the activated key remains 

30 illuminated while the back lights of all other 
keys in the field are extinguished. The user is 
then instructed to select the account from 
which funds are to be transferred and the 
back lights of all of the keys in the from 

35 account field are Dluminated. As the user 
selects the from savings key the back light of 
that key remains illuminated while the back 
lights of all other keys in the from account 
field are extinguished. The user is then in- 

40 structed to select the account to which the 
funds are to be transferred and all back 
lights in the to account field are illuminated. 
Upon selection of the checking account key, 
the activated key remains back lighted and 

45 the back lights of all other keys in the to 
account field are extinguished. The remain- 
ing back lights provide an audit trail so that 
a user may confirm or remind himself of 
the status of his transaction request entry. 

50 He can change his mind at any time by re- 
turning to a previously entered field activat- 
ing a new key and continuing the keyboard 
entry process from that point. Numerical in- 
formation such as the dollar amount of 

55 funds which are to be transferred is entered 
through the numeric field of keyboard 112. 
All entered numeric information is displayed 
for confirmation except the personal ID 
number. This number is not displaved in 

60 order to prevent surreptitious knowledge of 
the personal ID number by a person stand- 
ing behind the user. The keyboard data, 
credit card data read from the magnetic 
stripe, and any desired additional data are 

65 then provided in clear text behind the four 



70 



byte common header field and four byte 
encrypted field. This information is then 
communicated to the host data processing 
system 14 as a transaction request message. 

2. Transaction Reply Message 

Referring now to Fig. 4 as a transaction 
request message is received by th& host data 
processing system 12, it undergoes processing 
140 to separate the various fields of data 75 
with the common header field being used for 
message routing and with the 32 encrypted 
bits being passed through a decrypt 
algorithm 142 and the clear text being re- 
ceived by the host data processor 144 which 80 
has a large data storage 146. The decrypt 
algorithm 142 uses Key B which is the same 
third or transmission key which was utilized 
for encryption algorithm 124. The host data 
processor 12 utilizes the clear text data to 85 
access the user's data base record (file) data 
storage 146. This file contains account data 
as well as information associated with the 
user's credit card such as the encrypted 
personal ID number (or numbers). 90 

The 32 bits which are generated by de- 
cryption algorithm 142 are passed through a 
separation processor 148 wherein the 6 four 
bit digits of the encrypted personal ID 
number are separated from the two variable 95 
digits. A comparison 150 is then performed 
with the communicated 6 digits of the en- 
crypted ID number being compared with the 
6 digits of ID information from the file which 
were stored in encrypted form. 100 

This encryption process greatly improves 
the security of cash stored in the various 
transaction terminals 14 which may be in 
communication with an on line host data 
processing system. A person of ill intent who 105 
is in possession of the correspondence be- 
tween credit card account numbers and 
personal ID numbers could surreptitiously 
obtain cash from the terminal 14. For ex- 
ample, a person might forge or steal credit 110 
cards having information stored thereon 
which pertains to actual user accounts. Usin? 
the forged credit card and the correspond- 
ing personal ID number, a person could first 
inquire as to the balance of various savings, 115 
checking or other acounts which are acces- 
sible through the credit card. Having ob- 
tained the balance information, the person 
could then use the credit card and the cash 
issue terminal 14 to withdraw cash from 120 
those accounts until either the accounts or 
the terminal cash are depleted. Additional 
accounts with their credit card and corres- 
ponding personal ID number could be 
utilized in a similar manner until all of the 125 
cash at a cash issue terminal has been issued. 
The person could then move on to deplete 
the cash from additional cash issue terminals 
in the system using additional credit cards 
and personal ID numbers. Because each 130 
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cash terminal 14 may contain many thous- 
ands of dollars and because there may be 
many terminals 14 in communication with 
the host data processing system 12, it be- 
5 comes extremely important to maintain the 
correspondence between credit card account 
numbers and personal ID numbers secured 
and yet permit local checks to allow higher 
availability of terminals 14 through off line 

10 use. It becomes extremely difficult for a 
person to obtain the correspondence between 
the credit card information and personal ID 
numbers for a large number of accounts 
when the techniques described herein are 

15 employed. Even if the personal ID number 
may be completely generated by passage of 
the stored credit card information through 
encryption algorithm 106, security of its 
encryption Key A is maintained as des- 

20 cribed above. 

If the relationship of a portion (or pre- 
ferably all), for example the first three digits, 
of the personal ID number and the stored 
credit card information has no predeter- 

25 mined relation, it becomes even more dif- 
ficult to compromise the system. It is pos- 
sible that personnel at the data processing 
center for the host data processing system 
12 may have access to the stored encrypted 

30 ID number. However, the actual personal 
ID number is not stored in the host data 
processing system and the enervated ID 
number is of no value in obtaining cash 
from a terminal 14 since it is the actual 

35 personal ID number that must be entered 
through the keyboard of a terminal 14. It 
is thus necessary for a person seeking to ob- 
tain the corresoondence between a large 
number of credit cards and corresponding 

40 personal ID numbers to have access to both 
the encrypted personal ID numbers stored 
in the host data base and the decryption 
algorithm corresponding to encryption al- 
gorithm 118 and encryption Key A. 

45 As credit cards are issued it is possible to 
limit the knowledge of the correspondence 
between credit card data and personal ID 
numbers to a very few people. In fact, 
accounts can be established with part of the 

50 personal ID number being derived from the 
credit card information, and part being 
randomly generated by a computer. The 
total personal ID number can then be 
printed and sealed in an envelope along with 

55 a credit card such that the personal ID 
number is available to human eyes only 
after the envelope is given to a prospective 
user as he opens a credit card account which 
can be processed by a terrninal 14. It is thus 

60 possible to develop an assignment system 
wherein no banking personnel have access 
to the correspondence between credit card 
accounts and the associated personal ID 
number. 

65 If the comparison 150 shows that the 



stored and communicated encrypted personal 
ID numbers are not identical, the host data 
processing system assembles and communi- 
cates a transaction reply message indicating 
that execution of the transaction is not 70 
authorized. The transaction reply message 
might direct the requesting terminal 14 to 
either retain or return the user credit card. 
On the other hand, if the stored and com- 
municated encrypted ID numbers are found 75 
to correspond, and if the requested transac- 
tion does not violate any predetermined rules 
which might relate to dollar amounts, rates 
of withdraw, or account balances, the trans- 
action is authorized by a transaction reply 80 
message. The transaction reply message con- 
tains 32 bits of encrypted information corres- 
ponding to the 32 bits of encrypted informa- 
tion which are received in the transaction 
request message. In an assembling process 85 
152, 32 bits are assembled for encryption 
with encryption algorithm 154 using Key B, 
which is the third, transmission encryption 
key. The encryption algorithm may in 
general be any suitable encryption algorithm 90 
but for this example it is assumed that the 
algorithm is identical to encryption al- 
gorithms 106, 118 and 124. It is further 
assumed that Key B is identical to the Key 
B for encryption algorithm 124. The 32 95 
bits which are assembled for encryption are 
different from the communicated 32 bits 
which contained the 6 digits of encrypted ID 
number and two variable digits. The 32 bits 
of the transaction reply message include a 100 
one byte cash counter number correspond- 
ing to a first cash count <CNTR 1) main- 
tained by a terminal 14 which is incremented 
for each bill issued, an action byte which 
indicates the response the terminal 14 is to 105 
take to the requested user transaction, a 
second cash counter byte (CNTR 2) identi- 
fying the cash count which is maintained for 
a second cash issue mechanism within the 
terminal 14 and an amount byte (AMT) 110 
which indicates the number of bills which 
is relevant to the requested transaction. 
These 32 bits are then processed through 
encryption algorithm 154 to form 32 en- 
crypted bits 156. The encrypted bits 156 are 115 
then combined with clear text data such as 
optional display data, optional receipt data, 
or additional data required to complete the 
transaction and communicated back to the 
requesting terminal 46 and as a transaction 120 
reply message in step 158. 
3 . Execution and Status Message 
As the transaction reply message is re- 
ceived by the terminal 14 the message under- 
goes input processing 160 to check for 125 
transmission accuracy and separate the reply 
message into its various fields. The en- 
crypted field is passed through a decryption 
algorithm 162 which uses Key B to restore 
the 32 bits containing the cash counter one 130 
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(CNTR 1), ACTION, cash counter two 
(CNTR 2) and amount data (AMT). These 
bytes are checked for accuracy to ensure 
that the transaction reply message was re- 
5 ceived error free and that it corresponds to 
the correct transaction request message. A 
transaction conclusion 164 is then executed 
in accordance with the contents of the trans- 
action reply message. In concluding a trans- 
it) action, the terminal 14 returns or retains 
the credit card, issues appropriate docu- 
ments such as cash or printed transaction 
statements, formally executes or cancels the 
transaction, displays appropriate messages 

15 to allow the user's approval or disapproval; 
and performs any additional transaction exe- 
cution functions which are necessary for 
completion of the transaction. 
Upon completion of a user requested 

20 transaction, the terminal 14 communicates 
a status message to the host data processing 
system 12 which informs the data processing 
system 12 of the manner in which the re- 
quested transaction was terminated and the 

25 status of the terminal 14. Preparation of the 
status message includes assembly 166 of 32 
bits which are encrypted with encrypted 
algorithm 168 using Key B to gener- 
ate 32 encrypted bits 170. The en- 

30 cryption algorithm 168 may in general be 
any suitable encryption algorithm but 
for the preferred embodiment presented 
herein, encryption algorithm 168 is identical 
to encryption algorithms 106, 108, 118, 124, 

35 and 154. Key B is identical to Key B for 
encryption algorithms 124 and 154. How- 
ever, unlike Key A, Key B may be changed 
by the host data processing system 12 and 
it is anticipated that Key B would be 

40 changed from time to time. The 32 bits 170 
undergo output processing 172 as they are 
combined with non-encrypted status in- 
formation and transmitted as a status mes- 
sage from the transaction execution terminal 

45 14 to the host data processing system 12. 
The method of using encryption algorithms 
as described herein provides great security 
for the transaction execution system 10 with- 
out requiring the storage capacity for stor- 

->0 mg the multiple encryption programs. Fur- 
thermore, with the proper selection of the 
encryption and decryption algorithms the 
decryption algorithm can be quite similar 
to the encryption algorithm to permit a 

m double usage of most of the encryption 
algorithm program for both encryption and 
decryption. This results in a further savings 
of program storage -requirements. The last 
encryption of the 32 bits of encrypted in- 

w formation in the three user transaction mes- 
sages permits security of the encrypted ID 
number along the communication channel 
while permitting the same general format 
to be utilized for all three messages. In the 

o5 transaction request message, assembly pro- 



cess 122 combines the encrypted ID num- 
ber with varying data to make it extremely 
difficult for a person monitoring the com- 
munication lines to break Key B and en- 
cryption algorithm 124 by repeatedly enter- 70 
ing the same ID number, credit card and re- 
quest and monitoring the corresponding 
encrypted communications. The transac- 
tion reply message contains a counter one 
byte, an action byte, a counter two byte and 75 
an amount. This information is all dif- 
ferent from the encoded information of 
the transaction request message and also 
contains varying information. The amount 
and the action byte will tend to be the same 80 
for the same types of transaction request, 
however the control bytes will change. The 
32 encrypted bits of the status message are 
different from the encrypted fields of either 
of the other two messages in that they con- 85 
tain the transaction number which is time 
varying, the counter two and counter one 
bytes in different byte positions from the 
transaction reply message and a count byte 
(CB) which indicates (via a binary count) 90 
the number of status and inquiry data bytes 
which follow the encrypted portion of the 
message for a normal status message. A 
status message which is generated in response 
to a transaction termination would normally 95 
contain no inquiry data byte. In the event 
that the status message is a "request re- 
covery" type of exception status message, 
the third byte (CB) of the encryption field 
contains the "action" byte from the transac- 100 
tion reply message for the last request Thus, 
by changing Key B from time to time and 
sending different information in the en- 
crypted portion of each different type of 
message, the task of breaking the transmis- 105 
sion encryption algorithm and finding the 
current Key B by monitoring the com- 
munication lines is made extremely difficult 
Even if the transmission encryption al- 
gorithm and Key B were broken, monitoring 110 
the transmission of messages would produce 
a correspondence between accounts and en- 
crypted personal ID numbers only for speci- 
fic credit cards which are used while the 
communication is being monitored. The 115 
assembly of a large number of forged or 
stolen credit cards and corresponding per- 
sonal ID numbers could be accomplished 
only by further breaking the Key A. In an 
alternative embodiment where there is a pre- 120 
determined relationship between all digits 
of the personal ID number and information 
on the credit card, access to the data base is 
not necessary. Keys Kl and K2 of course 
provide further security for the encrypted 125 
ID number in the event that the local ID 
check option is implemented. 

WHAT WE CLAIM IS: — 

1. A controlled access system including 
testing means, a request station incorporat- 130 
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ing encoding means, a control station in- 
corporating encoding means and a com- 
munication system for transmission of data 
between the request station, the control 

[ 5 station and the testing means, the arrange- 
ment being such that a request for access 
includes the entry of two messages at the 
request station, one of which is encoded at 
the request station, the other being encoded 

10 at the control station, the testing means be- 
ing arranged to generate an access enabling 
signal if there is correspondence between 
the encoded forms of the two messages. 
1. A system as claimed in claim 1 where- 

15 in the testing means is located at the control 
station. 

3. A system as claimed in claim 2 where- 
in the request station is incorporated in a 
data processing terminal and the testing 

20 means and control station are incorporated 
in a host data processor. 

4. A system as claimed in claim 3 in 
which the data processing terminal is a 
transaction terminal dependent upon host 

25 processor for approval and recordation of 
transactions indicated by a user, the transac- 
tion terminal including a data input device 
for entering a user determined block of 
identification information; an encoder con- 

30 nected to encode at least a portion of the 
block of identification information to pro- 
duce a first encrypted block of identification 
information indicative of at least a portion 
of the identification block of information; 

35 an encoder connected to encode at least a 
portion of the first encrypted block of 
identification information to produce a 
second encrypted block of identification in- 
formation indicative of at least a portion of 

40 the identification block of information; and 
a transmission system arranged to feed at 
least a portion of the second encrypted block 
of identification information to the com- 
munication system for transmission to the 

45 host processor. 

5. A system as claimed in claim 4 in 
which the terminal further includes a device 
for generating a block of variable informa- 
tion which changes with each user transac- 

50 tion and wherein the second encrypted block 
producing encoder is further connected to 
encode a block of variable information along 
with at least a portion of the first encrypted 
block of identification information to pro- 

55 duce a second encrypted block of identifica- 
tion information indicative of both variable 



information and at least a portion of the 
block of identification information. 

6. A system as claimed in claim 4 in 
which the terminal further includes means 60 
for storing first and second encryption keys 
and wherein the first and second encoded 
blocks of information are produced in re- 
sponse to the first and second encryption 
keys respectively. 65 

7. A system as claimed in claim 4 where- 
in the block of identification information is 
of a length less than a predetermined length 
and further comprising means for expand- 
ing a data block length connected to receive 70 
a short data block of a length less than a 
predetermined length from the data input 
device, expand the received data block to a 
predetermined length by adding characters 
which are dependent upon the data content 75 
of the short data block, and provide a data 
block which has been expanded to a pre- 
determined length to the first encrypted 
block producing encoder. 

8. A system as claimed in claim 7 above, 80 
wherein the expanding means expands a 
short block of data by adding characters 
which are generated from the process of 
taking the logical exclusive-or of selected 
portions of the short block of data. 85 

9. A system as claimed in claim 4 in 
which the terminal further includes means 
for reading prerecorded information from a 
user produced card, an encoder connected 

to encode a selected portion of the pre- 90 
recorded information read from a card to 
produce a block of encrypted card informa- 
tion, and a comparator connected to compare 
a selected portion of the block of identifica- 
tion information received by the data input 95 
device with a corresponding selected por- 
tion of the block of encrypted card informa- 
tion and indicate the identity or non-identity 
of the compared data. 

10. A system as claimed in claim 9, the 100 
terminal further including means responsive 

to the identity or non-identity indication for 
inhibiting the transmission of said at least 
a portion of the second encrypted block to 
host. 105 

11. A controlled access system substan- 
tially as hereinbefore described with refer- 
ence to and as illustrated in the accom- 
panying drawings. 

L M. GRANT, 
Chartered Patent Agent, 
Agent for the Applicants. 
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